Project Description

Drammer is a new attack that exploits the Rowhammer hardware vulnerability on Android devices. It allows attackers to take control over your mobile device by hiding it in a malicious app that requires no permissions. Practically all devices are possibly vulnerable and must wait for a fix from Google in order to be patched. Drammer has the potential to put millions of users at risk, especially when combined with existing attack vectors like Stagefright or BAndroid.

Drammer is the first Android root exploit that relies on no software vulnerability and is an instance of the Flip Feng Shui exploitation technique. After Dedup Est Machina and Flip Feng Shui, Drammer is our group’s third in a series of Rowhammer exploitation research. Our Drammer exploit and companion Drammer test app (see below) were implemented in collaboration with the University of California, Santa Barbara.

Rowhammer

is a hardware bug that allows attackers to manipulate data in memory without accessing it. More specifically, by reading many times from a specific memory location, somewhere else in memory a bit may flip (a one becomes a zero, or a zero becomes a one). Our work is the first to show that Rowhammer is possible on mobile, ARM-based hardware.

Flip Feng Shui

or FFS is a technique that allows for reliable exploitation of a hardware vulnerability (e.g., Rowhammer) by combining it with a memory massaging primitive (to land sensitive data on a vulnerable location). Drammer is the first to show that such deterministic Rowhammer exploitation is possible without relying on fancy memory management features. Although we focus mainly on mobile devices, this makes that Drammer comes with a wider impact; allowing FFS attacks without memory deduplication, for example.

Papers

Drammer Test App

We developed an Android app – not yet in Google Play, but available directly – to test your device for the Rowhammer bug. The app uses a native binary for which we also released the source code. After a successful run, the app uploads anonymized output. We will use this to get a better understanding of how widespread the Rowhammer bug is. Of course, you can opt out of sharing results.

Please note the following:

Currently, when finished its hammering session, the app does not give you a nice popup that tells you whether you are vulnerable or not. We will try to add this as soon as possible. Meanwhile, you can easily spot induced bit flips by glancing over the output and looking for the obvious keyword FLIP.
Your phone might still be vulnerable, even if the app detected zero flips! There are two main reasons for this. First, our current implementation of address selection is conservative: we recently discovered that the current code is only hammering half of the rows on a Nexus 5. On your device, the DRAM geometry might be different enough for our app to completely fail selecting addresses for double-sided rowhammer. Second, the app may only have tested a very small fraction of your DRAM. Ideally, a single run takes at least an hour and scans a couple hundred of MB. The current code already tries to free as much memory as possible to hammer (affected by the aggressiveness factor), but there are probably better ways of doing this.

Hammertime simulator

We developed Hammertime, an open-source Rowhammer simulator – available on github – to foster further research on the Rowhammer bug. The simulator allows researchers and practitioners to simulate hardware bit flips in software, using bit-flip patterns (or fliptables) from a large set of DRAM chips. We plan to integrate bit-flip patterns we observed with Drammer on ARM soon.

Statistics

Not every phone is susceptible for the Rowhammer bug. For our paper, we tested 27 devices and were able to flip bits on 18 of them. In the table below, you can find statistics on devices that were tested so far.

Model	#devices	#vulnerable
ARMv7 (32-bit) devices
LG Nexus 4	1	1
LG Nexus 5	15	12
Motorola Moto G (2013)	1	1
Motorola Moto G (2014)	1	1
OnePlus One	2	2
Samsung Galaxy S4	1	1
Samsung Galaxy S5	2	1
ARMv8 (64-bit) devices
HTC Desire 510	1	0
Lenovo K3 Note	1	0
LG G4	1	1
LG Nexus 5X	1	0
Samsung Galaxy S6	1	0
Xiaomi Mi 4i	1	0

We encourage everybody to try our Drammer test app and help figuring out how widespread mobile Rowhammer is. We expect, for example, that devices equipped with LPDDR4 are less vulnerable. This is because the LPDDR4 standard includes optional hardware support for the so-called target row refresh mitigation.

Demos

The first demo video shows Drammer against an unrooted LG Nexus 5 running Android 6.0.1 with the latest security patches (as of October 5, 2016).
https://www.youtube.com/embed/x6hL-obNhAw

Our second video shows a successful end-to-end exploit chain of Stagefright (to get remote code execution) in combination with Drammer (to gain root privileges). By tricking the victim into opening a malicious URL, an attacker gains remote shell access to the vulnerable device. Since the exploited mediaserver is not running with root-privileges, however, he still cannot access /sdcard, for example. The attacker then launches the Drammer exploit which does give him full control over the device.
https://www.youtube.com/embed/0pV-Q9Q5s4Q
Note that we did not write our own Stagefright exploit, but gratefully used Metaphor from NorthBit. You can find our Stagefright shellcode here (requires SELinux to be disabled). Second, in the video, we upgrade our netcat remote shell after successful Stagefright exploitation so that we can use raw input and use tab-completion. The C source and Makefile for this pty-shell are also available online.

In the Dutch television show Universiteit van Nederland, we applied the Stagefright + Drammer attack to hack a phone of somebody in the audience.

Technical Walkthrough

Drammer presents two novel contributions: 1) being able to do Rowhammer on mobile devices, and 2) doing deterministic Rowhammer exploitation without relying on fancy memory management features. What follows is a technical summary of our paper, but only if you’re interested.

OK, give me details!

1. Mobile Rowhammer

Although functioning fairly well on x86, researchers have speculated that Rowhammer on ARM could be impossible. One of the main reasons being that the ARM memory controller might be too slow to induce bit flips. Not surprisingly, before Drammer, no existing work from academia or industry documents any success in reproducing the Rowhammer bug on mobile devices.

The obvious first goal of our study was to find bit flips on a mobile phone. Since Rowhammer manifests itself in DRAM, existing hammer code usually consists of a small loop that 1) reads a value from memory, and 2) flushes this value from the CPU cache. Without cache flushing, the vulnerable DRAM chip would only be accessed once during the first iteration. Every subsequent access would be served from the cache.

Working with an ARMv7-A CPU (the core of our poor LG Nexus 5 test phone), cache flush instructions are unavailable from user space (unlike Intel’s clflush instruction). We thus implemented a hammer function as Loadable Kernel Module. This allowed us to use the DCCIMVAC instruction (Data Cache Clean and Invalidate by MVA to PoC: mcr p15, 0, <reg>, c7, c14, 1). After some frustrating trial and error – do we not see any flips because of a bug in our code, is the controller really too slow, or is this DRAM chip simply not vulnerable? – we found a first flip. Later, once we established that the ‘row size’ of the Nexus 5 is 64 KB instead of 256 KB, this one flip became many…

1b. Direct Memory Access

Although good for feasibility analysis, flipping bits with kernel code that requires root access is not practical for writing a root exploit. Our next goal was thus to induce bit flips from user space. After establishing that existing methods for flushing or bypassing the CPU cache do not work on ARM, we tried a new approach: using direct memory access (DMA). By design, DMA memory pages have two important properties: 1) they are marked as uncached; and 2) they are physically contiguous. The former means that any read operation from DMA memory (or any write operation to it) bypasses the CPU cache and propagates to the DRAM chip directly. The latter means that pages obtained by allocations up to a certain size (4 MB on recent Linux kernels) are guaranteed to be adjacent to each other in physical memory.

DMA memory thus solves our problem of not being able to flush the CPU cache. The fact that allocated pages are physically contiguous happens to also solves another important issue. Recent kernels disabled access to /proc/self/pagemap – a special file containing the mapping of virtual to physical addresses. Without such mapping, it is hard to figure out from which ‘aggressor’ address x we should read to hammer ‘victim’ address y (x should be exactly one row above or below y to get the best chance of flipping it). If we know, however, that a chunk of memory is physically contiguous, we can compute aggressor addresses for each victim within such chunk by subtracting (or adding) the row size.

1c. Android ION

Android provides DMA Buffer Management APIs through its main memory manager called ION. This allows userland apps to access uncached, physically contiguous memory and comes with all the benefits:

We do not have to rely on cache flush instructions. Moreover, since we bypass the cache completely, we break any defense that relies on monitoring cache misses (e.g., ANVIL).
We do not have to rely on access to /proc/self/pagemap or transparent huge pages (which may not be enabled by default).
We do not have to rely on fancy memory management features like memory deduplication or MMU paravirtualzation for the memory massaging phase of FFS (discussed next).

Although ION is specific to Android, we think that it is also possible to construct similar attacks on Linux/x86-64. We dedicate a section about this in our paper.

2. Deterministic Exploitation

Armed with uncached, physically contiguous memory, our third goal is to perform memory massaging in such a way that a single bit flip allows us to gain root privileges. Similar to Mark Seaborn’s attack, we use page tables as sensitive data. By flipping a bit in a Page Table Entry (PTE), we can make that entry point to a page table. This means that the associated virtual address of that PTE is now mapped to a page table which we can use to overwrite its contents. Next, we can map any physical memory address into the virtual address range defined by the page table, including kernel memory. We can use this to search for our process’ credentials structure – the data structure that the kernel uses to keep track of a process’ uid, gid, etcetera. Finally, once found, we can modify our process’ struct cred to get root privileges.

A subtle difference between the exploit from Project Zero and Drammer is determinism. Mark Seaborn sprays physical memory with pages tables and reasons that when a PTE’s physical page number changes [due to a bit flip] there’s a high probability that it will point to a page table for our process. Drammer, however, removes this non-determinism by massaging physical memory in such a way that when we flip a bit in a PTE, we make it point to its own page table. We do this by using the bit flip as addition or subtraction primitive.

2b. Flipping Bits in Page Table Entries

As an example, consider a PTE that points to a page at physical address 0x1982f000. Ignoring the lowest 12 properties bits of a 32-bit PTE, this gives the bit pattern 00011001100000101111 (0x1982f000 bit shifted 12 places to the right). If a we manage to flip the lowest 1, then the new PTE becomes 00011001100000101110. This makes the PTE point to physical address 0x1982e000, showing that a 1-to-0 flip at this offset subtracts the PTE by one page. If we flip the second 1, we would end up with PTE 00011001100000101101. This corresponds to physical address 0x1982d000; exactly two pages away from the original. Flipping the third bit moves the PTE 4 pages to the left, the 4th bit allows us to move 8 pages, etcetera.

With these primitives in hand, we ought to align physical memory in such a way that the physical address of an mmapped data page is exactly n² pages ‘away’ from its page tabl. Here n is the offset of the vulnerable bit in the PTE. Continuing previous example, if n is 5 for a 1-to-0 flip, our data page should store 16 pages before the page table. And we found a way of doing exactly this 🙂

2c. Abusing the Buddy Allocator

By releasing a large contiguous memory chunk and quickly re-allocating smaller ones, we can satisfy above requirements and make Drammer deterministic. The basic steps of our attack involve:

Search physical memory for potentially exploitable flips (dubbed templating). After this step, we have exhausted all large contiguous chunks (of size 4 MB), but also all medium-sized chunks – say of size 64 KB. This means that there is no physically contiguous memory left that spans 64 KB or more.
Release a large chunk that has an exploitable flip, but do hold the other chunks.
Allocate (i.e., exhaust) all medium-sized chunks again. Since, in step 1, we exhausted all of these already, we know that the buddy allocator will split the large, vulnerable chunk that we released in step 2 and give us exactly 64 chunks of size 64 KB (64 * 64 KB = 4 MB), including a chunk with the exploitable bit. We can now release all chunks that are larger than 64 KB so that we won’t go out-of-memory in the next step.
Release the vulnerable medium-sized chunk and force the OS to allocate a page table at the location of vulnerable page (the page with the exploitable bit).
Map (with mmap) the appropriate other medium-sized chunk to create a page table entry that points to a page that is exactly n² pages away from the page table.

Next is hammer time! We hammer the row that holds the PTE to induce the bit flip that makes it point to its own page. We suddenly get write access to a page table and scan kernel memory by writing new PTEs. Once we find our credentials data structure, we overwrite it with zeros and get root access.

2d. Phys Feng Shui

The figure below illustrates the memory massaging phase of Drammer. For more details, it’s best to have a look at the paper.

drammer-ffs

Reception

Drammer gathered extensive media coverage. The responsible disclosure process was started on July 25. In conjunction with Google, we did not publicly disclose any details about Drammer prior to the CCS conference in Vienna. Google informed their partners about this issue on October 3, 2016 and provided a patch for it in their November Android Security Bulletin.

Ultimately, CVE-2016-6728 was assigned to this issue. Our bug report and Proof-of-Concept received a reward from the Android Security Reward Program. The vulnerability was marked as Critical by Google.

Note that, although Google’s patch round from November complicates our attack, it does not eradicate it. We hope to see a more sophisticated fix soon.

More details

Frequently Asked Questions

Why the name Drammer?

Drammer (or actually DRAMMER) may be short for Deterministic RowhAMMER. However, it is also a combination of the words DRoid and hAMMER and also has the part DRAM in it. Finally, in Dutch, Drammer means nag or pusher. Take your pick!

How wide-spread is Mobile Rowhammer? How can I check whether my phone is vulnerable?

We don’t know yet, but you can help us finding out. We developed a Drammer test app for you to play with.

I have a phone with LPDDR4 memory. Am I safe against Drammer attacks?

Again, we don’t know. Chances are that your DRAM comes with the Target Row Refresh (TRR) mitigation, which makes it harder – but still not impossible, in theory – to induce bit flips. Moreover, TRR for LPDDR4 is optional, so your DRAM manufacturer may have decided to drop this technique and leave you vulnerable.

Will my device receive a patch to stop Drammer attacks?

This depends on your device’s vendor. We expect that Google’s first patch will get back ported to recent devices. Since a more comprehensive solution requires fundamental kernel changes, however, it is unlikely that such patch ever reaches existing devices. Ultimately, it is up to your device vendor to decide whether or not they will adopt proposed fixes.

I have an older phone and am unlikely to get any updates. Now what?

If you’re lucky, your device is not vulnerable for Rowhammer – did we mention our Drammer test app? If it is, you’ll have to be careful about what apps you install. Make sure that you disable the allow app installation from unknown sources feature to get the best protection.

I constantly monitor installed apps for suspicious events. Am I safe against Drammer attacks?

You’re probably hinting at recent techniques like ANVIL, [BHUSA’15], or the mitigation proposed by the Linux kernel developers. By monitoring cache misses, such mitigations can only detect Rowhammer attacks that execute many cache flushes. Unfortunately, Drammer hammers uncached (DMA) memory and thus never triggers a cache miss. In fact, we expect that no existing anomaly detection system can stop Drammer.

I want to use Drammer to root my phone. Where can I download the exploit code?

You cannot. We decided to not (yet) release the exploit. We did open source our templating code, however.

Acknowledgements

This work was supported by the Netherlands Organisation for Scientific Research through grants NWO 639.023.309 VICI “Dowsing” and NWO CSI-DHS 628.001.021, by the European Commission through under programme GA No. 644571 (SHARCS), programme GA No. 644052 (HECTOR), and programme GA No. 610436 (MATTHEW), by the ONR under Award No. N00014-15-1-2948 and Award No. N00014-17-1-2897, by the NSF under Award No. CNS-1408632, by DARPA under agreement No. FA8750-15-2-0084, and by Google through a Security, Privacy and Anti-Abuse award. The public artifacts reflect only the authors’ view. The funding agencies are not responsible for any use that may be made of the information they contain.

vusec

Drammer: Flip Feng Shui Goes Mobile